It is well known to monitor the performance of computer system resources generally and web pages in particular. A typical web page is comprised of a myriad of http requests to various assets which are combined into a single document object model. For example, a web page can typically generate hundreds of http requests. Web browsers allow a finite number of concurrent http requests to run in parallel when a page is loaded. Therefore, rendering and other functions of the web page can require an undesirable amount of time. A web page that takes too long to render, or otherwise operates slowly, will likely create a poor user experience.
FIG. 1 is a schematic illustration of a very simple web page. The Web page is typically represented by HTML code. The HTML code can have various references to objects, such as graphics, frames, or the like, that are stored remotely in a distributed manner. In FIG. 1, HTML code 10 contains references to objects 12, 14, and 16 which can be stored on the same device as HTML code 10 or on another device. Further, object 14 references object 18. One or more of objects 12, 14, 16, and 18 can be more complex objects such as JavaScript Object Notation (JSON) objects. JSON is a language-independent data format used primarily to transmit data between a server and a web application. JSON objects can be complex and can require many data requests and responses.
Accordingly, Web pages can be very complex and there can be thousands of requests and responses that must be accomplished in order to load the page. A “waterfall” chart, which shows the cascading order and timing of http requests as a page loads, can be used to visualize data that is generated cumulatively and sequentially during a page load. Such charts can illustrate the series of actions that occur between a client computer and a server during a page load or other activity. FIG. 2 illustrates a simple example of a waterfall chart.
Each Process, 1-N, represents a request required for the page load. N can be a very high number, such as several thousand. Each request is mapped over time. Some requests occur before rendering has started and some occur after rendering has started. It can be seen that some requests are accomplished in parallel and some n seriatim. Further, many requests can be accomplished in association with a single feature of the web page. For example, one feature might be to embed a live stock feed or a video in a web page.
Website stakeholders often set time based page load goals generally measured in seconds. A typical acceptable page load time for a web page may range anywhere from 2 seconds to 10 seconds depending on the nature and purpose of the web page being served. Page load goals are established to ensure that the user experience meets predetermined expectations. In order to meet these goals, the time it takes for the browser to consider a page “document complete” must be determined. This typically corresponds to the Java Script on load event which usually happens after all content is loaded but may not include content that is triggered by JavaScript execution. All additional JavaScript executions, after document complete, and any other possible events are then added to the document complete time to determine when a page is fully loaded.
FIG. 3 is a table of web page load data. In the example of FIG. 3, the user experienced a document complete page load time of 9.395 s. During this time, 365 http requests were made and 2,732 kilobytes of data was loaded. In order for all content to fully load, an additional 124 http requests were made totaling 489 requests with an additional 2,031 kilobytes of data downloaded totaling 4,763 kilobytes.
Many of these 489 requests are able to run in parallel (or asynchronously). However, modern browsers have limits on the number of requests that can be made per domain as well as the total number of requests that can be made. Also, the browser must schedule requests to be made. These factors mean that more requests generally results in more time to load. Even though these requests may not be directly blocking another request, they are getting scheduled when other requests could be scheduled instead, and they are contributing to the total available request slots per page. Finally, if multiple requests for a feature are going through the same domain, they can block each other based on maximum limitations per domain.
Various tools and services have been developed to monitor and measure to performance of web pages, such as measuring the time for rendering a page, checking for bad links and checking for missing files. Also, it is known to process web page performance data to provide better visibility into page performance. For example, WEBPAGETEST.ORG provides “waterfall”, content, and connection timing charts for any web page.